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Automatic re-authentif ication in a terminal client-server architecture 



(57) Upon successfully authenticating a client de- 
vice (1 4) with a server system (12), the client device (14) 
and server system (12) share auto -reconnect data, in- 
cluding a session ID and a first random number Upon 
subsequently losing and re-establishing communica- 
tions with the server system (12), the client (14) sends 
an auto-authenticate request to the server (12). The au- 
to-authenticate request includes a session verifier that 



is based at least in part on the shared auto- reconnect 
data. The server (1 2) validates the session verifier. If the 
validation is successful, the server (1 2) automatically re-"" 
authenticates the client device (14). Optionally upon re- 
quest of auto-authenticate to the server (12) a second 
random number is generated and shared, and the ses- 
sion identifier is based at least in part on a combination 
of said first and second random numbers. 
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Description 
TECHNICAL FIELD 

[0001] The invention relates to user and session au- 
thentication in systems having remote terminals. 

BACKGROUND 

[0002] Certain versions of the Microsoft® Windows® 
server operating system support "Terminal Services." 
Using Terminal Services, a server system can deliver a 
conventional Windows® desktop, as well as the latest 
Windows®-based applications, to a remotely located 
desktop computing device which is referred to as a client 
device or remote terminal. The remote terminal is often 
a personal computer running specialized terminal emu- 
lation software. In the Microsoft® Windows® environ- 
ment described herein, the remote terminal runs soft- 
ware that is specifically designed for operation with Win- 
dows® Terminal Services. 

[0003] When a user runs an application in this envi- 
ronment, most or ail of the application execution, data 
processing, and data storage take place on the server; 
only things such as keyboard, mouse, display, and print 
information are transmitted back and forth between the 
server and the remote terminal. 

[0004] A single server system can support multiple 
users and corresponding user sessions. Each user logs 
on and sees only their individual session, which is man- 
aged transparently by the server operating system and 
is independent of any other client session. 
[0005] Communications between the server system 
and the various remote terminals are frequently by 
means of a network of some sort. The network might be 
a private local-area network, a private or public wide- 
area network, or a publicly-accessible network such as 
the Internet. Various forms of encryption are utilized be- 
tween the server system and the remote terminals to 
ensure privacy and data integrity over these otherwise 
unsecure forms of network communications. Both the 
server system software and the remote terminal soft- 
ware are designed to support this encryption. 
[0006] Microsoft® Windows® Terminal Services uti- 
lizes RDP (remote desktop protocol), a presentation 
services protocol that governs communications be- 
tween the server system and the remote terminals. RDP 
uses its own video driver on the server system to render 
display output by constructing the rendering information 
into network packets and sendingthem overthe network 
to the client device. The client receives the rendering 
data and interprets it into corresponding Win32® GDI 
API calls. Similarly, client mouse and keyboard messag- 
es are redirected from the client to the server. At the 
server, RDP uses its own virtual keyboard and mouse 
driver to receive these keyboard and mouse events. In 
addition to these basic input/output functions, RDP pro- 
vides support for various other features, such as print 



M 
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redirection, clipboard mapping, remote control, and net- 
work load balancing. In addition, RDP enables data 
compression, data encryption, and logon and logoff 
services. RDP communications are typically packaged 

5 or embedded within the TCP/IP protocol. 

[0007] The server system is capable of executing, a 
number of different sessions. Each user session is typ- 
ically associated with a single user and remote terminal, 
although the same session might be associated with dif- 

10 ferent remote terminals during different time periods. To 
initiate a user session, the user establishes a secure 
connection between a particular client device and the 
server system. The server system then utilizes the I/O 
capabilities of the client device to authenticate the user, 

*5 in a process referred to as a "logon" process. Authenti- 
cation is typically performed by requesting user creden- 
tials, which normally comprise a user name and pass- 
word. Upon receiving valid credentials, the server sys- 
tem creates a session and connects the client device to 

20 that session. 

[0008] In many networked environments, and partic- 
ularly in the Internet environment, data connections are 
unreliable and can be easily lost. In the Terminal Serv- 
ices environment described above, losing data commu- 

25 nications between the server system and the client de- 
vice does not necessarily terminate the session associ- 
ated with that client device. Rather, the session is kept 
active for a predefined time period, and the user can log 
back on to that session using the same client device or 

30 a different client device. The logon process is similar to 
the initial logon process, in that the server system au- 
thenticates the user by requesting user credentials. 
Rather than creating a new session, however, the server 
system recognizes the user as being associated with an 

35 existing session, and reconnects the user to that ses- 
sion. In some systems, the client device might retain a 
session identifier from the previous session and submit 
the session identifier during the subsequent logon proc- 
ess to reconnect to that session. 

40 

SUMMARY 

[0009] Upon successfully authenticating a client de- 
vice with a server system, the client device and server 

45 system share auto-reconnect data. Upon subsequently 
losing and re-establishing communications with the 
server system, the client sends an auto-authenticate re- 
quest to the server. The auto-authenticate request in- 
cludes a session verifier that is based at least in part on 

50 the shared auto-reconnect data. The server validates 
the session verifier. If the validation is successful, the 
server automatically re-authenticates the client device. 

BRIEF DESCRIPTION OF THE DRAWINGS 

55 

[0010] 

Fig. 1 is block diagram of a client/server system that 
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incorporates elements of the invention described 
below. 

Figs. 2-6 are flowcharts showing steps performed 
by the server system and client devices shown in 
Fig. 1. 5 
Fig. 7 is a block diagram showing how components 
of the server system of Fig. 1 execute with regard 
to user and kernel modes of a computer. 
Fig. 8 is a block diagram of a exemplary computer 
that might be programmed to perform the functions 10 
described herein. 

DETAILED DESCRIPTION 

[0011] The following description sets forth specific 15 
embodiments and elements of a client/server system 
that incorporate elements recited in the appended 
claims. The embodiments are described with specificity 
in order to meet statutory requirements. However, the 
description itself is not intended to limit the scope of this 20 
patent. Rather, the inventors have contemplated that the 
claimed invention might also be embodied in other 
ways, to include different elements or combinations of 
elements similar to the ones described in this document, 
in conjunction with other present or future technologies. 25 
[0012] Fig. 1 shows an exemplary embodiment of a 
terminal server system 10. System 10 includes a server 
computer or system 12 and a plurality of remote termi- 
nals or client devices 14. Remote clients 14 communi- 
cate with server computer 1 2 by means of a network 1 6, 30 
which may be a local-area network, a wide-area net- 
work, a publicly-accessible network such as the public 
Internet, or some other type of data communications 
network. Alternatively, one or more of remote clients 14 
might utilize non-network means of communications 35 
with server system 12, such as dedicated or on-demand 
dial-up connections, or other forms of direct or point-to- 
point data communications. 

[0013] Both the server system 10 and the individual 
client computers are conventional, general desktop *o 
computers or computers of other types, although spe- 
cialized computers and other more specific-purpose de- 
vices might also be used to perform the functions of 
these components. A specific and detailed example of _ 
a computer suitable for performing the described func- 
tions will be set forth below, In conjunction with Fig. 8. 
[0014] In the described embodiment, server system 
12 runs a version of the Microsoft® Windows® server 
operating system and includes terminal server features 
such as those described above, generally referred to as 50 
"Terminal Services." As noted above, application pro- 
grams in this environment execute on server system 12 
rather than on the individual client devices 14. Key- 
board, mouse, display, and print information, however, 
is transmitted back and forth between the server and the 55 
remote terminal. This division of responsibility is gener- 
ally transparent to users. To a user, it appears just as if 
the applications were running on the client device; user 



4 

interface functions, including graphical interface ele- 
ments and user input functions are carried out through 
the client device. In many cases, the client device will 
be configured with terminal emulation software to coor- 
dinate these functions with the server. 
[0015] The Terminal Services of the Microsoft® Win- 
dows® server operating system executes multiple serv- 
er sessions in conjunction with remote terminals or client 
devices 14, wherein user applications execute primarily 
on the server system and user I/O is performed through 
the client devices. The term "session" refers generally 
to a set of changing state information associated with a 
given client device. In a terminal server environment 
such as that described herein, this state information re- 
sides on server system 12 rather than on individual cli- 
ent computers 14. The session or state information for 
a given client computer relates to whatever application 
programs are being executed by server system 12 on 
behalf of the client computer. 

[0016] It should be noted that although the invention 
is described as being implemented within the Micro- 
soft® Windows® server operating system and its Termi- 
nal Services components, other implementations are al- 
so contemplated. The invention can be used in a variety 
of situations where a server authenticates clients as a 
condition to allowing such clients to utilize services of 
the server. The invention is especially useful in situa- 
tions where server/client communications are unreliable 
and subject to interruptions. 

[0017] Figs. 2-5 show actions performed by server 
system 12 and client device 14 relating to authentication 
and automatic re-authentication after a communications 
failure. Note that the actions shown in Figs. 2-5 are per- 
formed by software running on either server system 12 
or on one of client devices 14. In the described embod- 
iment, the actions are integrated within the Terminal 
Services software running on server system 1 2 or within 
the terminal emulation software running on client devic- 
es 14. In other embodiments, the described actions can 
be integrated with other types of software. 
[0018] Fig. 2 shows actions performed by server 12 
in establishing a new session for a particular client de- 
vice. An initial action 20 comprises establishing a secure 
data communications channel between server system 
12 and client device 14. In the described embodiment, 
this is accomplished using the RDP (Remote Desktop 
Protocol) and various encryption techniques employed 
by RDP. RDP uses RC4, a secret key cryptographic 
method developed by RSA Data Security, Inc., of Red- 
wood City, California, to secure the communications 
channel. SSL (secure sockets layer) is another example 
of a security protocol that might be used to provide a 
secure communications channel. The term "secure" is 
used to indicate that communications between the serv- 
er and client are relatively free from potential intercep- 
tion or eavesdropping. When using a relatively unsecu re 
communications medium such as the Internet, commu- 
nications security is normally provided by encryption. 
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However, encryption may not be necessary if the com- 
munications medium itseif is secure. 
[0019] A subsequent action 22, which is performed 
over the secure communications channel using RDP, 
comprises authenticating the client or client device for 
a server session. In many cases, this action comprises 
a logon process in which the user is requested or 
prompted at the client device for user credentials such 
as a user name and password, which are in turn re- 
ceived and validated by the server. 
[0020] Although the user credentials often comprise 
a user name and password, other types of credentials 
may also be utilized. For example, the user might be 
prompted to provide biometric information such as a fin- 
gerprint or retinal scan, to provide a hardware token 
such as smart card or other device, or to provide some 
other form of Identification. 

[0021] In many cases, authentication will be under 
control of the server system 1 2, which transmits graph- 
ical prompts for display at client device 1 4 and in turn 
receives user credentials from client device 14. In some 
cases, the terminal emulation software running on client 
device 14 may have special security features that oper- 
ate in conjunction with the server software to enhance 
the security of the logon process. 
[0022] Following a successful authentication or logon 
process, an action 24 comprises initiating a session on 
server system 12 for the requesting client device. 
[0023] A further action 26, which can be performed 
before, after, or concurrently with initiating the client's 
session, comprises generating and sharing auto-recon- 
nect data with the client device. The auto-reconnect da- 
ta comprises a session ID number and a first random 
number. In the described embodiment, both of these 
numbers are generated by the server system 1 2 and 
sent to client device 1 4 over the secure communications 
channel. The session ID is a number that is associated 
with the client's current server session and that is unique 
among currently executing sessions. The first random 
number is a 16-byte number that is generated using a 
cryptograph ically secure random number generator, 
and might include pseudo-random numbers. 
[0024] An action 27 comprises storing the auto- recon- 
nect data at the server for later use. In conjunction with 
the auto-reconnect data, the server also stores a refer- 
ence to the server sessionTor which the auto -reconnect 
data was generated. 

[0025] Fig. 3 illustrates actions performed by client 
device 14 in establishing a new session for a particular 
client device. For the most part, these actions are coun- 
terparts of the actions illustrated by Fig. 4. 
[0026] An action 28 comprises requesting and estab- 
lishing a secure communications channel between cli- 
ent device 14 and server system 12, using RDP as de- 
scribed above. A subsequent action 29 comprises pro- 
viding user credentials to server system 12 in a logon 
process to authenticate client device 1 4 with server sys- 
tem 12 and to initiate a server session associated with 



client device 14. 

[0027] An action 30 comprises sharing auto-recon- 
nect data with the server system. As already described, 
the auto-reconnect data comprises a session ID number 

s and a first random number. In the described embodi- 
ment, both of these numbers are received from the serv- 
er system. In other embodiments, one or both of these 
numbers might be generated by the client device and 
sent to the server. 

w [0028] An action 31 comprises storing the auto-recon- 
nect data at the client device 14. For security purposes, 
these numbers are preferably stored in volatile program 
memory rather than in the non-volatile file system of the 
client device, so that the auto-reconnect data is difficult 

is to access from other application programs that might be 
executing on client device 14. 

[0029] Fig. 4 illustrates actions performed by client 
device 14 after losing and re-establishing communica- 
tions with server system 12. The loss of communications 

20 might result from a data error, timeout, communications 
media failure, or any one of a number of different events. 
In many cases, such a communications loss is tempo- 
rary, and the user is able to re-connect client device 14 
with server system 12 after a short delay. Reconnection 

25 often involves a manual step performed by the user. The 
reconnection process can, however be automated. 
Specifically, the terminal emulation software of client de- 
vice 1 4 can be designed to automatically and repeatedly 
attempt to reconnect to server system 12 after a com- 

30 munications loss. 

[0030] Whether or not the reconnection process is au- 
tomated, the eventual result is an action 33 of re-estab- 
lishing of a secure communication channel between cli- 
ent device 14 and server 12. Once such a communica- 

35 tions channel is re-established, the client and server 
share a second random number in an action 34. The 
second random number is a different value than the first 
random number, but is generated by server system 12 
in a manner that is similar or identical to generation of 

40 the first random number. Thus, the second random 
number is a 16-byte value that is received by client de- 
vice 14 from server system 12. 

[0031 ] An action 35 then comprises calculating or de- 
riving a client session verifier at the client device from 

45 at least a portion of the auto- reconnect data. More spe- 
cifically, this comprises deriving the client session veri- 
fier at least in part from the first random number, and at 
least in part from the second random number. In the de- 
scribed embodiment, the session verifier is a one-way 

so hash of some combination of the two random numbers. 
For example, the two numbers might be added, multi- 
plied, or concatenated together, after which a one way 
hash is performed on the result to yield the session ver- 
ifier. HMAC (hashed message authentication code) is 

55 an example of a suitable one-way hash function. Other 
hash functions could alternatively be used. 
[0032] An action 36 comprises requesting automatic 
re-authentication by the server system without providing 
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user credentials. In the described embodiment, this ac- 
tion comprises sending an auto-authenticate request 
from the client device to the server system. The auto- 
authenticate request includes (a) the session ID (previ- 
ously received in action 32) and (b) the session verifier 5 
calculated in the previous action. Assuming that this re- 
quest is successful, the client device is reconnected to 
the original server session. Note that the client device 
is not required to store the user credentials in order to 
provide automatic re-authentication. 10 
[0033] Fig. 5 illustrates actions performed by server 
system 12 after losing communications between client 
device 14 and server system 12. An action 38 comprises 
re-establishing a secure communications channel be- 
tween client device 1 4 and server system 1 2. This is ac- i $ 
complished in response to client-initiated communica- 
tions, utilizing the encryption features of RDP or other 
encryption technologies. 

[0034] A subsequent action 40 comprises generating 
and sharing the second random number between server 20 
system 12 and client device 14. In the described em- 
bodiment, this second random number is generated by 
server system 1 2 in a manner that is similar or identical 
to generation of the first random number. In other em- 
bodiments, the client device might be responsible for 25 
generating the second random number, and for sending 
it to server system 12. 

[0035] An action 42 comprises receiving the auto-au- 
thenticate request from the client device 14. As already 
mentioned, the auto-authenticate request includes (a) a 30 
session ID and (b) a client session verifier that has been 
calculated by the client device 14 as already described. 
[0036] An action 44 comprises calculating or deriving 
a server session verifier. The server session verifier is 
calculated in the same manner as the client session ver- 35 
ifier, by taking a one-way hash of the first and second 
random numbers. 

[0037] An action 46 comprises validating the client 
session verifier by comparing it to the server session 
verifier. If the two verifiers match, the validation is sue- 40 
cessful and an action 48 is performed of automatically 
re-authenticating the requesting client device for the 
session indicated by the session ID received in the auto- 
authenticate request — without requesting user creden- 
tials. Once authenticated for the requested session, the 45 
client device is re-connected to that session and normal 
session operations resume. If the two verifiers do not 
match, the validation is not successful and the auto-au- 
thenticate request is refused. In this case, the client de- 
vice is not re-connected to the requested session, and so 
a more conventional user logon process 50 is initiat- 
ed — typically requiring the user to enter his or her user 
credentials.. 

[0038] Actions 26 and 27 of Fig. 2 and actions 30 and 
31 of Fig. 3 are repeated every time a client device is 55 
re-authenticated for a particular session. That is, thefirst 
random number is re-generated and shared anew be- 
tween the server system and the client device after eve- 



ry successful re-authentication. This assures that only 
one client device at a time can connect to a particular 
session. 

[0039] As an optional feature, at least a portion of the 
auto-reconnect data is automatically regenerated and 
shared anew at predetermined time intervals. Specifi- 
cally, the first random number is re-generated and re- 
shared between server system 12 and client device 14 
approximately every hour. Once a newly generated first 
random number is shared between the server and the 
client, the old random number is invalidated and will no 
longer work for reconnection. 

[0040] Fig. 6 shows the process or periodically chang- 
ing the random number portion of the auto-reconnect 
data and sending it to the client. An action 66 comprises 
generating and sending the first random number to the 
client and recording a timestamp. A subsequent action 
68 comprises comparing the timestamp to the current 
time to determine whether a predetermined time period, 
such as an hour, has elapsed. If it has, execution loops 
back to action 66 where a new random number is gen- 
erated and sent to the client, and a new timestamp is 
recorded. If the time period has not expired, block 68 is 
reiterated until the result of the comparison is true, 
whereupon action 66 is executed again. 
[0041 ] Fig. 7 shows pertinent details of how the server 
system 14 is implemented within the operating system 
of a computer. In this embodiment, the computer has an 
operating system 70 which supervises what are known 
as user and kernel modes. Programs or program com- 
ponents typically run in one of these two modes. Kernel 
mode is typically reserved for lower-level system soft- 
ware components that are relatively critical to operation 
of the computer. Application programs typically run un- 
der the operating system in the non-kemel user mode, 
and make calls to components of the kernel mode in or- 
der to perform system-level functions. The kernel mode 
is typically supported by the microprocessor hardware 
of the computer. 

[0042] In the described embodiment of a terminal 
server system, there are one or more user-level server 
components 71 that manage user sessions and perform 
various functions associated with user sessions. In ad- 
dition, there are multiple protocol stacks or communica- 
tions components 72 that run within the kernel mode to 
perform lower-level communications functions between 
the server and the respective clients. Generally, there is 
a single protocol stack 72 for each session and corre- 
sponding client device 1 4. The stack manages commu- 
nications under the RDP protocol and under lower-level 
protocols such as TCP, IP, UDP, etc. Generally, commu- 
nications between server component 71 and the multi- 
ple protocol stacks 72 are by way of function calls made 
by server component 71 to stacks 72. 
[0043] In the described embodiment, the protocol 
stack 72 for a particular session is responsible for gen- 
erating and sending the first random number to the as- 
sociated client device, and for re-generating and re- 
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sending the first random number at periodic intervals. 
Specifically, every time protocol stack is called upon to 
perform server/client communications, it checks to see 
if the predetermined time period has elapsed and regen- 
erates and re-sends the first random number if the time 5 
period has elapsed. This allows the random number to 
be changed and resent without instigation by the termi- 
nal server component 71 . Using this technique, a new 
random number is sent only if the predetermined time 
period has elapsed and only if the protocol stack is ac- to 
tive in sending or receiving data. 
[0044] This architecture is advantageous because it 
avoids the use of a dedicated user-mode "spin" thread 
that might be otherwise necessary in order to periodi- 
cally re-send the first random number to the client at pe- is 
riodic intervals. The use of such a thread would poten- 
tially be expensive in terms of computer resources. 
Thus, the elimination of such a thread is a significant 
advantage. 

[0045] During the auto-reconnect process, a received 20 
auto-reconnect request is processed by a new protocol 
stack 72 and passed to terminal server component 71 . 
As part of this request, the terminal server component 
receives a session ID and a client session verifier. In 
order to find the current first random number associated 25 
with the session identified by the received session ID, 
the server component 71 identifies the protocol stack 72 
that was associated with the session before the com- 
munications failure, and queries that protocol stack for 
the most recent first random number that was shared 30 
with the client for that session. The server component 
then uses that random number to calculate the server 
session verifier and to validate the session verifier re- 
ceived from the client. 

[0046] The various components and functionality de- 35 
scribed above are implemented with individual comput- 
ers. Fig. 8 shows components of typical example of such 
a computer, referred by to reference numeral 100. The 
components shown in Fig. 8 are only examples, and are 
not intended to suggest any limitation as to the scope of 40 
the functionality of the invention; the invention is not 
necessarily dependent on the features shown in Fig. 8. 
[0047] Generally, various different general purpose or 
special purpose computing system configurations can 
be used. Examples of well known computing systems, «5 
environments, and/or configurations that may be suita- 
ble for use with the invention include, but are not limited 
to, personal computers, server computers, hand-held or 
laptop devices, multiprocessor systems, microproces- 
sor-based systems, set top boxes, programmable con- so 
sumer electronics, network PCs, minicomputers, main- 
frame computers, distributed computing environments 
that include any of the above systems or devices, and 
the like. 

[0048] The functionality of the computers is embodied 55 
in many cases by computer-executable instructions, 
such as program modules, that are executed by the 
computers. Generally, program modules include rou- 



tines, programs, objects, components, data structures, 
etc. that perform particular tasks or implement particular 
abstract data types. Tasks might also be performed by 
remote processing devices that are linked through a 
communications network. In a distributed computing en- 
vironment, program modules may be located in both lo- 
cal and remote computer storage media. 
[0049] The instructions and/or program modules are 
stored at different times in the various computer-reada- 
ble media that are either part of the computer or that can 
be read by the computer. Programs are typically distrib- 
uted, for example, on floppy disks, CD-ROMs, DVD, or 
some form of communication media such as a modulat- 
ed signal. From there, they are installed or loaded into 
the secondary memory of a computer. At execution, they 
are loaded at least partially into the computer's primary 
electronic memory. The invention described herein in- 
cludes these and other various types of computer- read- 
able media when such media contain instructions, pro- 
grams, and/or modules for implementing the steps and 
actions described above in conjunction with microproc- 
essors or other data processors. The invention also in- 
cludes the computer itself when programmed according 
to the methods and techniques described above. 
[0050] For purposes of illustration, programs and oth- 
er executable program components such as the operat- 
ing system are illustrated herein as discrete blocks, al- 
though it is recognized that such programs and compo- 
nents reside at various times in different storage com- 
ponents of the computer, and are executed by the data 
processor(s) of the computer. 

[0051] With reference to Fig. 8, the components of 
computer 100 may include, but are not limited to, a 
processing unit 120, a system memory 130, and a sys- 
tem bus 121 that couples various system components 
including the system memory to the processing unit 120. 
The system bus 121 may be any of several types of bus 
structures including a memory bus or memory controller, 
a peripheral bus, and a local bus using any of a variety 
of bus architectures. By way of example, and not limita- 
tion, such architectures include Industry Standard Ar- 
chitecture (ISA) bus, Micro Channel Architecture (MCA) 
bus, Enhanced ISA (EISAA) bus, Video Electronics 
Standards Association (VESA) local bus, and Peripher- 
al Component Interconnect (PCI) bus also known as the 
Mezzanine bus. 

[0052] Computer 100 typically includes a variety of 
computer-readable media. Computer-readable media 
can be any available media that can be accessed by 
computer 100 and includes both volatile and nonvolatile 
media, removable and non-removable media. By way 
of example, and not limitation, computer- readable me- 
dia may comprise computer storage media and commu- 
nication media. Computer storage media include both 
volatile and nonvolatile, removable and non-removable 
media implemented in any method or technology for 
storage of information such as computer-readable in- 
structions, data structures, program modules, or other 
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data. Computer storage media includes, but is not lim- 
ited to, RAM, ROM, EEPROM, Hash memory or other 
memory technology, CD-ROM, digital versatile disks 
(DVD) or other optical disk storage, magnetic cassettes, 
magnetic tape, magnetic disk storage or other magnetic 5 
storage devices, or any other medium which can be 
used to store the desired information and which can be 
accessed by computer 110. Communication media typ- 
ically embodies computer-readable instructions, data 
structures, program modules or other data in a modu- 10 
lated data signal such as a carrier wave or other trans- 
port mechanism and includes any information delivery 
media. The term "modulated data signal" means a sig- 
nal that has one or more if its characteristics set or 
changed in such a manner as to encode information in '5 
the signal. By way of example, and not limitation, com- 
munication media includes wired media such as a wired 
network or direct-wired connection and wireless media 
such as acoustic, RF, infrared and other wireless media. 
Combinations of any of the above should also be includ- 20 
ed within the scope of computer readable media. 
[0053] The system memory 130 includes computer 
storage media in the form of volatile and/or nonvolatile 
memory such as read only memory (ROM) 131 and ran- 
dom access memory (RAM) 132. A basic input/output 25 
system 133 (BIOS), containing the basic routines that 
help to transfer information between elements within 
computer 1 00, such as during start-up, is typically stored 
in ROM 131. RAM 132 typically contains data and/or 
program modules that are immediately accessible to 30 
and/or presently being operated on by processing unit 
120. Byway of example, and not limitation, Fig. 8 illus- 
trates operating system 134, application programs 135, 
other program modules 136, and program data 137. 
[0054] The computer 100 may also include other re- 35 
movable/non-removable, volatile/nonvolatile computer 
storage media. By way of example only, Fig. 8 illustrates 
a hard disk drive 141 that reads from or writes to non- 
removable, nonvolatile magnetic media, a magnetic 
disk drive 151 that reads from or writes to a removable, 40 
nonvolatile magnetic disk 152, and an optical disk drive 
155 that reads from or writes to a removable, nonvolatile 
optical disk 1 56 such as a CD ROM or other optical me- 
dia. Other removable/n on -removable, volatile/nonvola- 
tile computer storage media that can be used in the ex- 45 
emplary operating environment include, but are not lim- 
ited to, magnetic tape cassettes, flash memory cards, 
digital versatile disks, digital video tape, solid state 
RAM, solid state ROM, and the like. The hard disk drive 
141 is typically connected to the system bus 121 through 50 
an non-removable memory interface such as interface 
140, and magnetic disk drive 151 and optical disk drive 
155 are typically connected to the system bus 1 21 by a 
removable memory interface such as interface 1 50. 
[0055] The drives and their associated computer stor- 55 
age media discussed above and illustrated in Fig. 8 pro- 
vide storage of computer- readable instructions, data 
structures, program modules, and other data for com- 



puter 100. In Fig. 8, for example, hard disk drive 141 is 
illustrated as storing operating system 144, application 
programs 145, other program modules 146, and pro- 
gram data 1 47. Note that these components can either 
be the same as or different from operating system 134, 
application programs 135, other program modules 136, 
and program data 137. Operating system 144, applica- 
tion programs 145, other program modules 146, and 
program data 147 are given different numbers here to 
illustrate that, at a minimum, they are different copies. 
A user may enter commands and information into the 
computer 1 00 through input devices such as a keyboard 
162 and pointing device 161, commonly referred to as 
a mouse, trackball, or touch pad. Other input devices 
(not shown) may include a microphone, joystick, game 
pad, satellite dish, scanner, or the like. These and other 
input devices are often connected to the processing unit 
120 through a user input interface 160 that is coupled 
to the system bus, but may be connected by other inter- 
face and bus structures, such as a parallel port, game 
port, or a universal serial bus (USB). A monitor 191 or 
other type of display device is also connected to the sys- 
tem bus 1 21 via an interface : such as a video interface 
190. In addition to the monitor, computers may also in- 
clude other peripheral output devices such as speakers 
197 and printer 196, which may be connected through 
an output peripheral interface 195. 
[0056] The computer may operate in a networked en- 
vironment using logical connections to one or more re- 
mote computers, such as a remote computer 180. The 
remote computer 180 may be a personal computer, a 
server, a router, a network PC, a peer device or other 
common network node, and typically includes many or 
all of the elements described above relative to computer 
100, although only a memory storage device 181 has 
been illustrated in Fig. 8. The logical connections depict- 
ed in Fig. 8 include a local area network (LAN) 171 and 
a wide area network (WAN) 1 73, but may also include 
other networks. Such networking environments are 
commonplace in offices, enterprise-wide computer net- 
works, intranets, and the Internet. 
[0057] When used in a LAN networking environment, 
the computer 100 is connected to the LAN 171 through 
a network interface or adapter 170. When used in a 
WAN networking environment, the computer 100 typi- 
cally includes a modem 172 or other means for estab- 
lishing communications over the WAN 173, such as the 
Internet. The modem 172, which may be internal or ex- 
ternal, may be connected to the system bus 121 via the 
user input interface 160, or other appropriate mecha- 
nism. In a networked environment, program modules 
depicted relative to the computer 1 00, or portions there- 
of, may be stored in the remote memory storage device. 
By way of example, and not limitation, Fig. 8 illustrates 
remote application programs 185 as residing on mem- 
ory device 181. It will be appreciated that the network 
connections shown are exemplary and other means of 
establishing a communications link between the com- 
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puters may be used. 

[0058] Although details of specific implementations 
and embodiments are described above, such details are 
intended to satisfy statutory disclosure obligations rath- 
er than to limit the scope of the following claims. Thus, 
the invention as defined by the claims is not limited to 
the specific features described above. Rather, the in- 
vention is claimed in any of its forms or modifications 
that fall within the proper scope of the appended claims, 
appropriately interpreted in accordance with the doc- 
trine of equivalents. 



Claims 



1. A server system programmed to perform actions 
comprising: 

authenticating a client device for a particular 
server session; 

sharing auto-reconnect data with the client de- 
vice; 

after losing communications with the client de- 
vice, receiving from the client device a session 
verifier that is derived at least in part from the 
auto- reconnect data; 
validating the session verifier; 
upon successfully validating the session verifi- 
er, automatically re-authenticating the client 
device for the particular server session. 

2. A server system as recited in claim 1 , wherein said 
re-authenticating is performed without requesting 
user credentials. 

3. A server system as recited in claim 1 , wherein send- 
ing the auto-reconnect data is performed through a 
secure data communications channel. 

4. A server system as recited in claim 1 , wherein the 
auto-reconnect data comprises a random number. 

5. A server system as recited in claim 1, wherein the 
auto- reconnect data comprises a session ID asso- 
ciated with the particular server session and a ran- 
dom number. 

6. A server system as recited in claim 1 , wherein: 

the auto-reconnect data comprises a session 
ID associated with the particular server session 
and a random number; 

the session verifier is derived at least in part 
from the random number; . 
said actions further comprise, after losing com- 
munications with the client device, receiving the 
session ID from the client device. 



7. A server system as recited in claim 1 , wherein: 

said actions further comprise, after losing com- 
munications with the client device, sharing a 
5 random number with the client device; and 

the session verifier is derived at least in part 
from the shared random number and the auto- 
reconnect data. 

10 8. A server system as recited in claim 1 , wherein: 



said actions further comprise, after losing com- 
munications with the client device, sharing a 
random number with the client device; and 
the session verifier is a one-way hash based at 
least in part on (a) the shared random number 
and (b) the auto-reconnect data. 



15 
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9. A server system as recited in claim 1 , wherein: 

the auto-reconnect data comprises a first ran- 
dom number; 

said actions further comprise, after losing com- 
munications with the client device, sharing a 
second random number with the client device; 
the session verifier is derived at least in part 
from the first and second random numbers. 

10. A server system as recited in claim 1 , wherein: 

the auto-reconnect data comprises a first ran- 
dom number, 

said actions further comprise, after losing com- 
munications with the client device, sharing a 
second random number with the client device; 
the session verifier comprises a one-way hash 
based at least in part on the first and second 
random numbers. 



40 1 1 . A server system as recited in claim 1 , wherein said 
actions further comprise periodically changing at 
least a portion of the auto- reconnect data and send- 
ing at least said changed portion to the client device. 

45 12. A server system as recited in claim 1 , wherein the 
auto- reconnect data comprises a random number, 
said actions further comprising periodically chang- 
ing the random number and sending it to the client 
device. 

50 

1 3. A server system as recited in claim 1 , wherein val- 
idating the session verifier comprises calculating 
the session verifier at the server system and com- 
paring the calculated session verifier to the received 

55 session verifier. 

14. A server system as recited in claim 1 , further com- 
prising: 
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an operating system; 

one or more communication program compo- 
nents that execute in a kernel mode under the 
operating system; 

one or more server program components that 5 
execute in a non-kernel mode under the oper- 
ating system to implement server sessions; 

wherein the communication program compo- 
nents periodically resend at least a portion of the 10 
auto-reconnect data to the client device without in- 
stigation by the server program components. 

15. A server system as recited in claim 1 , further com- 
prising: 15 

an operating system; 

one or more communication program compo- 
nents that execute in a kernel mode under the 
operating system; 20 
one or more server program components that 
execute in a non-kernel mode under the oper- 
ating system to implement server sessions; 

wherein the communication program compo- 25 
nents periodically change and resend at least a por- 
tion of the auto-reconnect data without instigation 
by the server program components. 

16. A server system as recited in claim 1 , further com- 30 
prising: 

an operating system; 

one or more communication program compo- 
nents that execute in a kernel mode under the 35 
operating system; 

one or more server program components that 
execute in a non-kernel mode under the oper- 
ating system to implement server sessions; 

40 

wherein the communication program compo- 
nents, when communicating with the client device, 
(a) check to determine whether a predetermined 
time has elapsed since sending at least a portion of 
the auto-reconnect data, and (b) change and re- <*5 
send at least a portion of the auto- reconnect data 
without instigation by the server program compo- 
nents it the predetermined time has elapsed. 

17. A server system as recited in claim 1 , wherein: so 

said re-authenticating is performed without re- 
questing user credentials; 
the auto-reconnect data comprises a session 
I D associated with the particular server session 55 
and a first random number; 
sending the auto-reconnect data is performed 
through a secure data communications chan- 
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nel; 

said actions further comprise, after losing com- 
munications with the client device: 

receiving the session ID from the client de- 
vice; and 

sharing a second random number with the 
client device; 

the session verifier is derived at least in part 
from thef irst and second random numbers; and 
validating the session verifier comprises calcu- 
lating the session verifier at the server and com- 
paring the calculated session verifier to the re- 
ceived session verifier. 

18. A terminal server system programmed to perform 
actions comprising: 

executing multiple server sessions in conjunc- 
tion with remote terminals, wherein user appli- 
cations execute primarily on the terminal server 
system and user I/O is performed through the 
remote terminals; 

requesting user credentials to authenticate a 
particular remote terminal for a particular serv- 
er session; 

sharing auto- reconnect data with the particular 
remote terminal over a secure communications 
channel, the auto-reconnect data comprising a 
first random number; 

re- establishing communications with the partic- 
ular remote terminal after a communications 
failure; 

sharing a second random number with'the par- 
ticular remote terminal after re-establishing 
communications; 

receiving from the particular remote terminal a 
session verifier that is derived at least in part 
from the first and second random numbers; 
validating the session verifier; 
upon successfully validating the session verifi- 
' er, automatically re-authenticating the particu- 
lar remote terminal for the particular server ses- 
sion without again requesting user credentials. 

19. A server system as recited in claim 18, wherein: 

the auto-reconnect data further comprises a 
session ID associated with the particular server 
session; and 

said actions further comprise, after re-estab- 
lishing communications, receiving the session 
ID from the particular remote terminal. 

20. A server system as recited in claim 1 8, wherein the 
session verifier is a one-way hash based at least in 
part on the first random number. 
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21. A server system as recited in claim 1 8, the actions 
further comprising: 

after re-establishing communications, sharing 
a second random number with the particular re- 
mote terminal; 

wherein the session verifier is derived at least 
in part from the first and second random numbers. 

22. A server system as recited in claim 18, the actions 
further comprising: 

after re-establishing communications, sharing 
a second random number with the particular re- 
mote terminal; 

wherein the session verifier is a one-way hash 
based at least in part on the first and second random 
numbers. 

23. A server system as recited in claim 1 8, wherein said 
actions further comprise periodically changing said 
first random number and re-sending it to the partic- 
ular remote terminal. 



24. A server system as recited in claim 18, wherein val- 
idating the session verifier comprises calculating 
the session verifier at the terminal server system 
and comparing the calculated session verifierto the 
received session verifier. 

25. A server system as recited in claim 18, further com- 
prising: 

an operating system; 

one or more communication program compo- 
nents that execute in a kernel mode under the 
operating system; 

one or more server program components that 
execute in a non-kernel mode under the oper- 
ating system to implement server sessions; 

wherein the communication program compo- 
nents periodically change the first random number 
and re-send it to the particular remote terminal with- 
out instigation by the server program components. 



wherein the communication program compo- 
nents, when communicating with the particular re- 
mote terminal, (a) check to determine whether a 
predetermined time has elapsed since sending at 
the first random number, and (b) change the first, 
random number and re-send it to the particular re- 
mote terminal without instigation by the server pro- 
gram components if the predetermined time has 
elapsed. 

27. A client device programmed to perform actions 
comprising: 

providing user credentials to a server system to 
authenticate the client device with the server 
system; 

initiating a server session on a server system, 
the server session being associated with the cli- 
ent device; 

sharing auto-reconnect data with the server 
system, the auto-reconnect data comprising a 
session ID and a first random number; 
deriving a session verifier at least in part from 
the first random number, 
after losing and re-establishing communica- 
tions with the server system, requesting auto- 
matic re-authentication by the server system 
without providing user credentials, wherein 
said requesting comprises sending the session 
30 verifier to the server system. 

28. A client device as recited in claim 27, wherein: 

said actions further comprise, after losing com- 
35 munications with the server system, sharing a 

second random number with the serversystem; 
deriving the session verifier at least in part from 
both the first and second random numbers. 
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26. A server system as recited in claim 1 8, further com- 
prising: 

an operating system; 

one or more communication program compo- 
nents that execute in a kernel mode under the 
operating system; 

one or more server program components that 
execute in a non-kernel mode under the oper- 
ating system to implement server sessions; 



40 29. A client device as recited in claim 27, wherein said 
actions further comprise periodically sharing a 
changed first random number with the server sys- 
tem: 

45 30. A client device as recited in claim 27, wherein the 
auto-reconnect data is received from the server 
system: 

31. A client device as recited in claim 27, wherein said 
so requesting further comprises sending a session ID 
to the server system. 



32. A method comprising: 

55 establishing data communications between a 

client device and a server system; 
authenticating the client device for a particular 
server session; 
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sharing auto-reconnect data between client de- 
vice and the server system; 
deriving a client session verifier at the client de- 
vice from at least a portion of the auto- recon- 
nect data; 5 
re-establishing data communications between 
the client device and the server system after a 
communications failure; 
after re-establishing data communications, pro- 
viding the client session verifier from the client 10 
device to the server system; 
deriving a server session verifier at the server 
system from at least a portion of the auto-re- 
connect data; 

validating the client session verifier by compar- 15 
ing it to the server session verifier, 
upon successfully validating the session verifi- 
er, automatically .re-authenticating the client 
device for the particular server session. 

20 

33. A method as recited in claim 32, wherein said re- 
authenticating is performed without requesting user 
credentials. 

34. A method as recited in claim 32, wherein the auto- 25 
reconnect data comprises a random number. 

35. A method as recited in claim 32, wherein the auto- 
reconnect data comprises a session ID associated 
with the particular server session and a random 30 
number. 

36. A method as recited in claim 32, further comprising: 

after re-establishing data communications, 35 
sharing a random number between the client 
device and the server device; and 

wherein the client session verifier and server 
session verifier are derived at least in part from the 40 
shared random number and the auto-reconnect da- 
ta. 

37. A method as recited in claim 32, wherein: 

45 

the auto-reconnect data includes a first random 
number; 

the method further comprises, after re-estab- 
lishing data communications, sharing a second 
random number between the client device and 50 
the server device; and 

the client session verifier and server session 
verifier are derived at least in part from the first 
and second random numbers. 



38. A method as recited in claim 32, wherein: 

the auto-reconnect data includes a first random 



number; 

the method further comprises, after re-estab- 
lishing data communications, sharing a second 
random number between the client device and 
the server device; and 

the client session verifier and server session 
verifier comprise a one-way hash based at least 
in part on the first and second random numbers. 

39. A method as recited in claim 32, wherein said ac- 
tions further comprise periodically changing at least 
a portion of the auto-reconnect data and sharing at 
least said changed portion between the client de- 
vice and the server device. 

40. A method as recited in claim 32, wherein the auto- 
reconnect data comprises a random number, said 
actions further comprising periodically changing the 
random number and sharing it between the client 
device and the server device. 

41 . A method as recited in claim 32, further comprising: 

executing one or more communication program 
components in a kernel mode under an operat- 
ing system; 

executing one or more server program compo- 
nents in a non-kernel mode underthe operating 
system to implement server sessions; 
the communication program components peri- 
odically changing and resending at least a por- 
tion of the auto-reconnect data to the client de- 
vice without instigation by the server program 
components. 

42. A method as recited in claim 32, further comprising: 

executing one or more communication program 
components in a kernel mode under an operat- 
ing system; 

executing one or more server program compo- 
nents in a non-kernel mode underthe operating 
system to implement server sessions; 
the communication program components, 
when communicating with the client device, (a) 
checking to determine whether a predeter- 
mined time has elapsed since sending at least 
a portion of the auto-reconnect data, and (b) 
changing and resending at least a portion of the 
auto -reconnect data without instigation by the 
server program components if the predeter- 
mined time has elapsed. 

43. One or more computer-readable media containing 
55 instructions that are executable by a computer to 

perform actions comprising: 

establishing communications with a client de- 
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vice; 

requesting user credentials through the client 
device to authenticate the client device for a 
particular server session; 

sharing auto-reconnect data with the client de- 5 
vice, the auto-reconnect data comprising a first 
random number; 

re-establishing communications with the client 
device after a communications failure; 
receiving from the particular client device a ses- 10 
sion verifier that is derived at least in part from 
the first random number; 
validating the received session verifier; 
upon successfully validating the session verifi- 
er, automatically re-authenticating the particu- 15 
lar client device forthe particular server session 
without again requesting user credentials. 

44. One or more computer-readable media as recited 

in claim 43, wherein: 20 

the auto-reconnect data further comprises a 
session ID associated with the particular server 
session; and 

said actions further comprise, after re-estab- 25 
lishing communications, receiving the session 
ID from the client device. 

45. One or more computer-readable media as recited 

in claim 43, wherein the session verifier is a one- 30 
way hash based at least in part on the first random 
number. 

46. One or more computer-readable media as recited 

in claim 43, the actions further comprising: 35 

after re-establishing communications, sharing 
a second random number with the client device; 

wherein the session verifier is derived at least 40 
in part on the first and second random numbers. 

47. One or more computer-readable media as recited 
in claim 43, the actions further comprising: 

45 

after re-establishing communications, sharing 
a second random number with the client device; 

wherein the session verifier is a one-way hash 
based at least in part on the first and second random 50 
numbers. 

48. One or more computer-readable media as recited 
in claim 43, wherein said actions further comprise 
periodically changing said first random number and 55 
re-sending it to the client device. 

49. One or more computer-readable media as recited 



in claim 43, the actions further comprising: 

executing one or more communication program 
components in a kernel mode under an operat- 
ing system; 

executing one or more server program compo- 
nents in a non-kernel mode underthe operating 
system to implement server sessions; 
the communication program components peri- 
odically changing the first random number and 
re-sending it to the client device without insti- 
gation by the server program components. 

50. One or more computer-readable media as recited 
in claim 43, the actions further comprising: 

executing one or more communication program 
components in a kernel mode under an operat- 
ing system; 

executing one or more server program compo- 
nents in a non-kernel mode underthe operating 
system to implement server sessions; 
the communication program components, 
when communicating with the client device, (a) 
checking to determine whether a predeter- 
mined time has elapsed since sending at the 
first random number, and (b) changing the first 
random number and re-sending it to the client 
device without instigation by the server pro- 
gram components if the predetermined time 
has elapsed. 

51 . One or more computer-readable media containing ^ 
instructions that are executable by a client compu- 
ter to perform actions comprising: 

providing user credentials to a server system to 
authenticate the client computer with the server 
system; 

initiating a server session on a server system, 
the server session being associated with the cli- 
ent computer; 

sharing auto- reconnect data with the server 
system, the auto- reconnect data comprising a 
session ID and a first random number; 
after losing and re-establishing communica- 
tions with the server system requesting auto- 
matic re-authentication by the server system 
without providing user credentials, wherein 
said requesting comprises: 

sharing a second random number with the 
server system; 

deriving a session verifier at least in part 
from the first and second random numbers; 
sending the session verifier to the server 
system. 
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52. One or more computer-readable media as recited 
in claim 51, wherein said actions further comprise 
periodically sharing a changed first random number 
with the server system: 



53. One or more computer-readable media as recited 
in claim 51 , wherein the auto-reconnect data is re- 
ceived from the server system: 

54. One or more computer-readable media as recited 10 
in claim 51, wherein said requesting further com- 
prises sending a session ID to the server system. 
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